Date: Fri, 27 May 94 04:30:19 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #165 

To: Ham-Digital 


Ham-Digital Digest Fri, 27 May 94 Volume 94 : Issue 165 


Today's Topics: 
DSP questions (3 msgs) 
NOS with the Baycom Modem 
Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT? 
Probs with Micropower-2 
Quiet computers 
VHF Packet net questions 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 26 May 94 19:49:35 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: DSP questions 

To: ham-digital@ucsd.edu 


Is anyone out there aware of any experiments done in the use of DSP to 
produce simulated spatial displacement of audio tones as a function of 
their frequency? What I have in mind is being able to spread a pile-up 
by having the lower-frequency tones appear to be on the right and the 
higher ones on the left, in an experiment to see whether that helps pick 
out individual signals. Could such a thing be implemented using an 
ordinary sound-card with stereo outputs as the interface? 


73, Pete 
n4zr@netcom.com 
NOTE: New Address 


Date: 26 May 1994 21:16:54 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech! news-feed-1.peachnet.edu!news.duke.edu! eff! 
news.kei.com!ssd.intel.com!chnews! cmoore@network.ucsd.edu 

Subject: DSP questions 

To: ham-digital@ucsd.edu 


Peter G. Smith (n4zr@netcom.COM) wrote: 

: Is anyone out there aware of any experiments done in the use of DSP to 
produce simulated spatial displacement of audio tones as a function of 

: their frequency? 73, Pete n4zr@netcom.com 


Just such an analog design appeared in one of the amateur pubs a couple 
of years ago. It was a low-pass filter to the left ear and a high-pass 
filter to the right ear. It could easily be done with a soundcard. 


73, KG7BK, CecilMoore@Delphi.com 


Date: 27 May 1994 01:52:47 GMT 

From: ihnp4.ucsd.edu!agate!darkstar.UCSC.EDU!news.hal.COM!olivea! inews.intel.com! 
mipos2!dcurtis@network.ucsd.edu 

Subject: DSP questions 

To: ham-digital@ucsd.edu 


In article <2s33k6$mdk@chnews.intel.com> cmoore@ilx018.intel.com (Cecil A. Moore 
-FT-~) writes: 

>Peter G. Smith (n4zr@netcom.COM) wrote: 

>: Is anyone out there aware of any experiments done in the use of DSP to 
>: produce simulated spatial displacement of audio tones as a function of 
>: their frequency? 73, Pete n4zr@netcom.com 

> 

>Just such an analog design appeared in one of the amateur pubs a couple 
>of years ago. It was a low-pass filter to the left ear and a high-pass 
>filter to the right ear. It could easily be done with a soundcard. 

> 

>73, KG7BK, CecilMoore@Delphi.com 

> 

Ah, but to get spacial placement, what you want to do is alter 

the phase delay to each ear and keep the amplitude flat. The 

stereo effect is a function of phase, not amplitude. Each channel 

should be an all-pass function, with symetrically opposite group 

delay curves. Several years ago there was an analog circuit published 
in, I believe, Ham Radio that did just that. 


Some time in the early 80's, like maybe '83, there was an issue of 


either IEEE Spectrum or maybe the Proceedings of the IEEE that was an 
anniversary issue of some kind. The contents were seminal 

papers in several areas, one of which was a great paper on 

stereo audio and how it worked. This was when "Stereo Hi-Fi" 

was new and nifty stuff. (BTW, the other papers in the issue 

are equally nifty.) Anyway, go read the stereo paper and the 
silliness of using amplitude to get spatial placement will be 

quite apparent. 


The DSP version should be pretty simple -- Do an all-pass with 
linear group delay on one channel, and simply delay the other 
channel to place middle tones in the middle of space. 


73, Dave NGOX 
dcurtis@mipos2.intel.com 


Date: Fri, 27 May 94 02:40:39 GMT 

From: ihnp4.ucsd.edu! library.ucla.edu!csulb.edu!csus.edu!netcom.com!netcomsv! 
skyld! jangus@network.ucsd.edu 

Subject: NOS with the Baycom Modem 

To: ham-digital@ucsd.edu 


Jeff Please forward this to the appropriate newsgroup/individual 
TCP/IP WITH NO TNC 
By: Mike Hooper, KF6PU 

TNCs run in the kissmode and SCC cards such as the DRSI PCPA have long 
been the staple of most TCP/IPers running NOS and Net versions of the KA9Q 
Internet Suite of Protocols. There is a much less expensive and more 
elegant solution for a 1200 baud hardware interface. 

"Baycom" style modems have enjoyed international popularity for some time 
now among those running packet software that employs the "software tnc" 
approach. Baycom, PMP, and Eskay Packet (SP) V6.10 with the TFPCX driver 
are very popular. 

Most Baycom style modems are designed around either the AMD 7910 "World 
Chip" IC , Texas Instruments TCM 3105, or the EXAR 2206/2211 pair. Most 
commercial TNCs use these chips for the modem section. For example, the 
AEA PK-88 uses the AMD 7910, The Kantronics KAM and KPC-4 use the TCM 3105 
for VHF-UHF ports and the MFJ 1270/1274 use the EXAR pair. Few external 
parts are required for these modems and they are easy to construct. The 
TCM 3105 modem can be built for under $25.00 and can be built so small as 
to fit into a DB25 shell. 

Thanks to the efforts of Pawel Jalocha, SP9VRC (SP9VRC@SP9ZDN.POL.EU) 
(jalocha@chopin.ifj.edu.pl) a packet driver conforming (to a sufficient 
extent) to the "FTP packet driver specification" has been developed that 
serves as an interface between application software (e.g. KA9Q NOS) and a 
modem connected to the RS232 port (e.g. Baycom modem). This driver along 


with documentation and accessory files have been distributed in this 
country under the filename "AX25DRV.ZIP" . Be sure to use the January 4, 
1993 version as prior releases have bugs. 

Jawel's packet driver enables the use of unsquelched audio as the driver 
is able to deliver "channel busy" status by analyzing incoming data. 

The driver is loaded into memory before NOS is run. The utility 
"TERMIN.COM" is used to remove the driver from memory when one exits from 
NOS. Below is a batch file that sets up the driver for use on COM2 with 
NOS : 

@echo off 
Ce 
cd\net 
ax25 -b1200 -B2£8 -I3p -cd -h350 
nos.exe 
termin.com 
cls 

The switches invoked with ax25.com specify: 1200 baud, COM2, IRQ priority 
(given to IRQ 3 in this example), carrier detect option, and txdelay. 
Slottime and persist default to 100 msec. and 64 but are adjustable with 
the -s and -p switches. The software interrupt defaults to 0x60 but is 
adjustable from 60 through 63 with the -i switch. Carrier detect threshold 
and TXtail are also adjustable with the -T and -t switches. A switch need 
not be specified if the default value is used. 

Within AUTOEXEC.NOS is the following attach statement (your version of 
NOS must be compiled with the attach packet hardware interface option): 

attach packet 0x60 144 5 256 

I have been using this driver with both the WG7J and KB7YW versions of 
NOS for several weeks. My system utilizes three hardware interfaces two of 
which are handled by a DRSI card. During this period I have had the 
opportunity to use a KAM (v6.0), PK-88, and a PK-232 with the TAPR DCD mod 
and in no case have I found these superior to a TCM 3105 modem used with 
Jawel's ax25 driver. The driver does not work well on an XT clone. My 
computer is a 386-33 SX using a pair of 16550 AFNs. I find it useful to 
reset the computer before running NOS to "clear" the comports. 

Work is currently in progress on adapting the G3RUH 9600 modem for use 
with the AX.25 driver. Potential problems concerning interrupt latency 
issues may complicate matters. If success is achieved it would 
substantially reduce the cost of running TCP/IP at 9600 baud. 

-73- k£6pu@wb6ymh.#soca.usa 
mhooper@netcom.com 


73 es GE from Jeff 


Amateur: WA6FWI@WA6FWI.d#SOCA.CA.USA.NOAM 

Internet: jangus@skyld.grendel.com 

US Mail: PO Box 4425 Carson, CA 90749 
Phone: 1 (310) 324-6080 


| "You have a flair for adding 
| a fanciful dimension to any 
| story." 

| Peking Noodle Co. 


Hate "Green Card Lottery"? Want to help curb ignorant crossposting on Usenet? 
E-mail ckeroack@hamp.hampshire.edu for more information, or read news.groups. 


Date: 26 May 1994 15:28:23 GMT 

From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!hobbes.physics.uiowa.edu! 
news.uiowa.edu! icaen!drenze@network.ucsd.edu 

Subject: Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT? 
To: ham-digital@ucsd.edu 


Will somebody who's hooked their PacComm Tiny-2 OR Micropower-2 TNC to 
either a Radio SHack HTX-202 or another ICOM 2AT-compatible HT please 
e-mail me the wiring configuration? I've got a Micropower-2 but the 
company is currently out of manuals so I don't know how to get it 
wired. 


U 


__ /| | Doug Renze, NOYVW | 

\'o.0' | +1 319 339 7814 | Amateur Radio: 

=(___)= | drenze@icaen.uiowa.edu | Bringing the World Together 
| | 


Date: 26 May 1994 15:17:00 GMT 

From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gstefsd.com! 
howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu! 
news.uiowa.edu!icaen!drenze@network.ucsd.edu 

Subject: Probs with Micropower-2 

To: ham-digital@ucsd.edu 


Ergle. I'm having a prob that I hope really isn't one... 


I've got a Micropower-2 TNC hooked up to my computer, but don't have 
the radio hooked up yet (haven't got the cables and can't quite figure out 
how to wire it to the HTX-202/ICOM 2AT config). Well, I decided to switch 
it on today to play around with the commands and...nothing. I've done this 
before and gotten a nice startup screen followed by the "cmd>" prompt, but 
today I got absolutely zilch, though it does echo characters and character 
returns back to the screen so I don't really think anything's fried. Am 
I in some sort of weird mode somehow, and how can I get it back out of it? 

Or am I f£xxxed? 


_. /| | Doug Renze, NOYVW | 

\'o.0' | +1 319 339 7814 | Amateur Radio: 

=(___)= | drenze@icaen.uiowa.edu | Bringing the World Together 
U | | 


Date: Thu, 26 May 1994 13:30:05 GMT 

From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com! 
greg@network.ucsd.edu 

Subject: Quiet computers 

To: ham-digital@ucsd.edu 


Here's a different subject... 


What specific brands/models of PCs have folks found to be particularly 
good or bad with regard to RF hash generated, and suseptability to 
RF fields? 


I'll start: my Compudyne 38625SXL (Twinhead) notebook is pretty good as far 
as generating noise, below 10.15 Mhz. On 20 meters, and up, it's 

pretty much of a disaster, growing worse as the frequency increases, 

even when run on battery power and equipped with split ferrites on 

all external cables. The LCD display seems to be part of the problem. 


On the plus side, it tolerates fields which are equal or greater to 
what the PK232 can take. 


Greg 


Date: 26 May 1994 21:53:10 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech!nntp.msstate.edu!Ra.MsState.Edu! 
cll4@network.ucsd.edu 

Subject: VHF Packet net questions 

To: ham-digital@ucsd.edu 


We are currently trying to get a VHF packet net started to increase the 
general use of packet in our area. We have been having trouble deciding 
what format to use to get everyone together. We have considered an unproto 
via 2 area digis, connecting to a net/rom (I think) node and using a talk 
feature (which sends each user's packet to everyone individually), and are 
out of ideas of a smooth way to accomplish this. There will be some people 
who will have to digipeat to get into our area. Any and all ideas will be 
welcome, and if anyone has such a beast currently running, I would love to 
hear from you. 


Thanks in advance, 


Craig 

Craig Lindsey - KC5AUG | My politics are simple: Always go right. If 
Internet: cll4@ra.msstate.edu| you go left, you can never go right, and if 
Bitnet: cll4@msstate.bitnet| you go right, you never go wrong. -Grizzard 


Packet: kcSaug@w5vzf.ms.usa.noam 


Date: Thu, 26 May 1994 14:47:25 GMT 
From: ihnp4.ucsd.edu!pacbell.com!amdahl!juts.ccc.amdahl.com!szb50@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <CqBqo0.5Ju@eskimo.com>, <2sOhvr$mko@u.cc.utah.edu>, 
<CqELxr.201A@icsbelf.co.uk> 

Reply-To : szb50@JUTS.ccc.amdahl.com (Sid Boyce) 

Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) 


Anonymous ftp col.hp.com /hamradio/packet/n6égn/uwavelink(multi megabaud) 


ftp.ucsd.edu has stuff .... tapr9600.mod and 96man.txt if you are 
looking for 9600 baud info. 


73 Sid Boyce ... G3VBV .... Amdahl(UK) ... G3VBV@GB7BHM.#29.GBR.EU 


Date: Thu, 26 May 1994 21:54:03 GMT 
From: ncrgw2.ncr.com!ncrhub2! ranger!cn2935.DaytonOH.NCR.COM! jra@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <548.18.uupcb@totrbbs.atl.ga.us>, <CqBqo0.5Ju@eskimo.com>, 
<2sOhvr$mko@u.cc.utah.edu> 


Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) 


In article <2sOhvr$mko@u.cc.utah.edu> val@cs.weber.edu (Val Kartchner) writes: 
>In article <CqBqo0.5Ju@eskimo.com> rdonnell@eskimo.com (Bob Donnell) writes: 
>>I'm suprised John didn't mention it - the new TAPR NETSIG mailing list is 
>>heavily involved in discussing 9600 (and faster) modem/radio issues. 


>How do I read this mailing list? Is it a packet-only mailing list, or 
>is it available to Internet users? 


ObPlug: 


The TAPR NetSIG mailing list is devoted to discussion of amateur packet radio 
networking issues. It's not limited to hardware discussions, though there's 
plenty of that going on right now. 


To subsrcribe, send a message to listserv@tcet.unt.edu with "join netsig" in 
the body. To submit messages, send to netsig@tcet.unt.edu. 


Note: the list has been very busier -- busier than we had ever hoped -- and 
as a result we recently had to change homes, and there have been a few bugs in 
the system. Please bear with us. 


John AG9V 
jra@lawdept.daytonOH.ncr.com 


PS -- No, I don't know much about the NCR Wavelan stuff, despite my address. 
I wish I did, but I've never been able to get my hands on any surplus units. 


Date: Thu, 26 May 1994 21:46:29 GMT 
From: ncrgw2.ncr.com!ncrhub2! ranger!cn2935.DaytonOH.NCR.COM! jra@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <jra.131.000A4F59@lawdept.daytonOH.ncr.com>, 
<548.18.uupcb@totrbbs.atl.ga.us>, <CqBqo0.5Ju@eskimo.com>rh 
Subject : Re: 9600 bps radio modems 


In article <CqBqo0.5Ju@eskimo.com> rdonnell@eskimo.com (Bob Donnell) writes: 


>Also, as a side note, when we've done testing here on link reliability we 
>usually are using the 'ping' feature of tcp/ip and NOS to do the testing. 
>We run 'datagram' (unconnected) mode and usually use 200-400 byte packets. 
>I have noticed that with two analog modems (TAPR on one end, PK-900/PK-96/ 
>TAPR/G3RUH on the other) that the best ping response I can get is about 95% 
>through our TAPR bit-regen modem equipped 2M repeater. This is over about a 
>45 mile line-of-site path. Switching to a DSP-2232 will improve the ping 


>return rate to about 98-99%. Kudoes to N4HY. Note that due to atmospherics 
>(ducting, etc) and the fact that the repeater is at about 5000 feet we have 
>times when the path to the repeater is poor to unusable, too. This is part 
>of why our next generation of repeaters are at low altitude sites, mostly 
>cell sites. 


Here's another data point: we do our testing on the 19.2 repeater the same 
way, via ping, usually with a 256 byte packet and 3 or 4 second interval. 


We also see ping hit rates of about 95% at best, 85% or so at worst, 
through the repeater (with reasonable but not pile-driver paths, and some 
other activity on the system). In bench tests, we get up to 98-99 percent. 


The non-returns generally are about evenly spaced, with occasional clusters of 
two or three drops in a row. Even over very long tests, we almost never see a 
run of more than 100 pings without a drop. 


This is using the D4-10 as an RF modem, directly driven by modem disconnect 
header or PI card. No scrambler. And, unfortunately, no bit regen (yet). 
I'm very interested in seeing whether adding bit regen is going to improve 
error rates generally, or only help on marginal signals. We're hoping to add 
a regen later this summer (once I can get a TAPR 9600 modem kit to butcher). 


John AG9V 
jra@lawdept.daytonOH.ncr.com 


Date: 26 May 1994 19:28:36 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech!howland.reston.ans.net!spool.mu.edu!torn! 
hermes.acs.ryerson.ca!ee.ryerson.ca! jeff@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <2q8erk$qdc@hermes.acs.ryerson.ca>, 
<1994May23.061932.641@beacons.cts.com>, <CqBL25.85r@world.std.com> 
Subject : Re: PacketRadio forLinux with Baycom ?? 


Daniel T Senie (dts@world.std.com) wrote: 

: In article <1994May23.061932.641@beacons.cts.com> kevin@beacons.cts.com (Kevin 
Sanders) writes: 

: >In article <2q8erk$qdc@hermes.acs.ryerson.ca> jeff@ee.ryerson.ca (Donald Jeff 
Dionne) writes: 

: >> 

: >>said that, however, there is a driver for Linux that does audio over the 

: >>pc speaker using a timer and some sort of PWM, and it works unless the 

: >>machine is busy with disk I/O or the like..... If you don't mind packet 

: >>loss when the machine is busy, and the machine comming to a halt when 

: >>packet is going on (as it does with the pc speaker), then perhaps I'm 


: >>wrong and it's worth a try. 

: > 

: >I experimented with a similar project; I wrote a driver which speeds up 
: >the system clock and samples one of those AEA fax interface units, to 

: >try to get HF fax running under Linux. I found that the IDE disk driver 
: >(at least for Linux 0.99.10 or so) disabled interrupts for long enough 
: >to skew my picture by 5-10% of the width each time a sync() occured :-( 
> 

: >I did not notice any other delays besides the IDE disk. I now have 

: >a SCSI-based system and it may not exhibit this problem. I also heard 
: >that the Linux IDE driver has been improved lately and does not disable 
: >interrupts for as long as it used to. 


: Actually, many of the SCSI adapters, such as the 1542 from Adaptec, are 
BUS MASTER devices. This means that the main CPU cannot get on the bus 

: to service interrupts at all during some periods. Bus mastering is a 

: desirable way to improve performance for DMA on disk controllers. Expect 

: to see lots more bust mastering on the newer bus achitectures. 


No, I have a 1542 in my Linux box, and it does not steal enough cycles to 
cause a problem with anything :-) 


: > 

: >Bottom line is, you must use the timer interrupt for polling as it is 
: >the highest priority; and also you had better have as good (or better) 
: >an understanding of the behavior of every driver, wrt locking out 

: >interrupts, as the people who wrote them. It's probably safest to 

: >determine this empirically, by cranking up the tick speed and counting 
: >the ticks for a few hours. Beat on the system as hard as you can during 
: >this time, and see if you missed any ticks (by checking against a 

: >real clock). You should be able to nail down the maximum tick rate 

: >permissible and then decide if this is fast enough sampling for your 

: >application. 


Yes. With a 386dx33, you can get 20k interrupts per second. That's 
an order of magnitude more than needed. On a 486dx2-66, 70k. On 
even a 386dx33, the impact on system performance would be acceptable, 
perhaps even go un-noticed! Seems I was wrong... this is do-able. 


: Bottom line is, a PC's main processor makes a terrible SCC controller. 

: the BAYCOM and PMP approaches are neat little hacks that really can 

: only work when you're talking about a DOS based machine that can run 

: without any preemption. Windows, Unix, Linux, OS/2, and most operating 

: systems have preemptive scheduling. Sure you can tweak them to handle 

: the timing needed for a $50 BAYCOM modem, though you run the risk of 
having to spend considerably more on enough computer horsepower to 


hit the timing windows, and enough of your time to make it non-cost 
: effective. 


You are right, of course. It's not a good solution, but cost effective? 
I think so. No, there's no profit to be make, but once the code is 
written, packet under Linux is much more affordable for those that don't 
have (or want to spend) the extra for a real TNC. 


: What I find odd, is that spending another $50 to get to $100 and buy a 

: real TNC, that can handle the synchronous communications of the packets 

: on the air, handle the HDLC framing, etc. is MUCH simpler than trying 

: to hack a multi-threaded or multi-processing OS into being able to 
handle a BAYCOM modem. Sometimes the hardware solution is cheaper... 


It's only cheaper the first time. If it could be made to work, BAYCOM 
style modems for Linux would open up packet to new users for far less 
than any other solution. 


: > 

Dan N1JEB 

Daniel Senie Internet: dts@world.std.com 
: Daniel Senie Consulting nijeb@world.std.com 
: 508-779-0439 Compusetrve: 74176 ,1347 


Date: Thu, 26 May 1994 09:49:03 GMT 
From: ihnp4.ucsd.edu! swrinde! pipex!uknet!icsbelf!mark@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <548.18.uupcb@totrbbs.atl.ga.us>, <CqBqo0.5Ju@eskimo.com>, 
<2sOhvr$mko@u.cc.utah.edu> 
Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) 


Is there an ftp archive or, even better, a WWW server for information on 
high speed packet? Perhaps someone would like to run a server at their site? 


We'll be doing some 9600 links here in GI soon, and I'm hoping to get some 
info to help me get things going. 


-mark 
Mark Willis Internet: mark@icsbelf.co.uk 
ICS Computing Group Ltd. Packet: GIOPEZ@GB7TED.#63.GBR.EU 


Belfast AmprNet: 44 .131.15.3 


Northern Ireland CompuServe: 100317,3025 


End of Ham-Digital Digest V94 4165 
KAKKKKKKKKKKK KKK KKKKKEKKERKEKR KAKA K 


